Method and apparatus for a relay to transmit a direct communication request message in a wireless communication system

ABSTRACT

A method and device are disclosed from the perspective of a User Equipment-to-User Equipment (UE-to-UE) Relay to perform a PC5 unicast link establishment procedure. In one embodiment, the method includes the UE-to-UE Relay receiving a first PC5-S message from a first User Equipment (UE), wherein the first PC5-S message includes a Layer-2 Identity (ID) of a second UE. The method further includes the UE-to-UE Relay transmitting a second PC5-S message addressed to the Layer-2 ID of the second UE for establishing a PC5 unicast link with the second UE. The method also includes the UE-to-UE Relay receiving a third PC5-S message from the second UE, wherein the third PC5-S message is transmitted by the second UE in response to reception of the second PC5-S message.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present Application claims the benefit of U.S. Provisional PatentApplication Ser. No. 63/040,976 filed on Jun. 18, 2020, the entiredisclosure of which is incorporated herein in their entirety byreference.

FIELD

This disclosure generally relates to wireless communication networks,and more particularly, to a method and apparatus for a relay to transmita direct communication request message in a wireless communicationsystem.

BACKGROUND

With the rapid rise in demand for communication of large amounts of datato and from mobile communication devices, traditional mobile voicecommunication networks are evolving into networks that communicate withInternet Protocol (IP) data packets. Such IP data packet communicationcan provide users of mobile communication devices with voice over IP,multimedia, multicast and on-demand communication services.

An exemplary network structure is an Evolved Universal Terrestrial RadioAccess Network (E-UTRAN). The E-UTRAN system can provide high datathroughput in order to realize the above-noted voice over IP andmultimedia services. A new radio technology for the next generation(e.g., 5G) is currently being discussed by the 3GPP standardsorganization. Accordingly, changes to the current body of 3GPP standardare currently being submitted and considered to evolve and finalize the3GPP standard.

SUMMARY

A method and device are disclosed from the perspective of a UserEquipment-to-User Equipment (UE-to-UE) Relay to perform a PC5 unicastlink establishment procedure. In one embodiment, the method includes theUE-to-UE Relay receiving a first PC5-S message from a first UserEquipment (UE), wherein the first PC5-S message includes a Layer-2Identity (ID) of a second UE. The method further includes the UE-to-UERelay transmitting a second PC5-S message addressed to the Layer-2 ID ofthe second UE for establishing a PC5 unicast link with the second UE.The method also includes the UE-to-UE Relay receiving a third PC5-Smessage from the second UE, wherein the third PC5-S message istransmitted by the second UE in response to reception of the secondPC5-S message.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a diagram of a wireless communication system according toone exemplary embodiment.

FIG. 2 is a block diagram of a transmitter system (also known as accessnetwork) and a receiver system (also known as user equipment or UE)according to one exemplary embodiment.

FIG. 3 is a functional block diagram of a communication system accordingto one exemplary embodiment.

FIG. 4 is a functional block diagram of the program code of FIG. 3according to one exemplary embodiment.

FIG. 5 is a reproduction of FIG. 5.2.1.4-1 of 3GPP TS 23.287 V16.2.0.

FIG. 6 is a reproduction of FIG. 6.1.1-1 of 3GPP TS 23.287 V16.2.0.

FIG. 7 is a reproduction of FIG. 6.1.2-1 of 3GPP TS 23.287 V16.2.0.

FIG. 8 is a reproduction of FIG. 6.3.3.1-1 of 3GPP TS 23.287 V16.2.0.

FIG. 9 is a reproduction of FIG. 6.1.2.2.2 of 3GPP TS 24.587 V16.0.0.

FIG. 10 is a reproduction of FIG. 6.8.2-1 of 3GPP TR 23.752 V0.3.0.

FIG. 11 is a reproduction of FIG. 6.9.2-1 of 3GPP TR 23.752 V0.3.0.

FIG. 12 is a reproduction of FIG. 6.1.6-1 of 3GPP TS 38.321 V16.1.0

FIG. 13 is a reproduction of FIG. 6.1.6-2 of 3GPP TS 38.321 V16.1.0.

FIG. 14 is a reproduction of Table 6.2.4-1 of 3GPP TS 38.321 V16.1.0.

FIG. 15 illustrates an example of an integrated PC5 unicast link via aUE-to-UE Relay according to one embodiment.

FIG. 16 illustrates an example of an integrated PC5 unicast linkestablishment procedure according to one embodiment.

FIG. 17 is a flow chart according to one exemplary embodiment.

DETAILED DESCRIPTION

The exemplary wireless communication systems and devices described belowemploy a wireless communication system, supporting a broadcast service.Wireless communication systems are widely deployed to provide varioustypes of communication such as voice, data, and so on. These systems maybe based on code division multiple access (CDMA), time division multipleaccess (TDMA), orthogonal frequency division multiple access (OFDMA),3GPP LTE (Long Term Evolution) wireless access, 3GPP LTE-A orLTE-Advanced (Long Term Evolution Advanced), 3GPP2 UMB (Ultra MobileBroadband), WiMax, 3GPP NR (New Radio), or some other modulationtechniques.

In particular, the exemplary wireless communication systems devicesdescribed below may be designed to support one or more standards such asthe standard offered by a consortium named “3rd Generation PartnershipProject” referred to herein as 3GPP, including: TS 23.287 V16.2.0,“Architecture enhancements for 5G System (5GS) to supportVehicle-to-Everything (V2X) services (Release 16)”; TS 24.587 V16.0.0,“Vehicle-to-Everything (V2X) services in 5G System (5GS); Stage 3(Release 16)”; TR 23.752 V0.3.0, “Study on system enhancement forProximity based services (ProSe) in the 5G System (5GS) (Release 17)”;and TS 38.321 V16.1.0, “NR; Medium Access Control (MAC) protocolspecification (Release 16)”. The standards and documents listed aboveare hereby expressly incorporated by reference in their entirety.

FIG. 1 shows a multiple access wireless communication system accordingto one embodiment of the invention. An access network 100 (AN) includesmultiple antenna groups, one including 104 and 106, another including108 and 110, and an additional including 112 and 114. In FIG. 1, onlytwo antennas are shown for each antenna group, however, more or fewerantennas may be utilized for each antenna group. Access terminal 116(AT) is in communication with antennas 112 and 114, where antennas 112and 114 transmit information to access terminal 116 over forward link120 and receive information from access terminal 116 over reverse link118. Access terminal (AT) 122 is in communication with antennas 106 and108, where antennas 106 and 108 transmit information to access terminal(AT) 122 over forward link 126 and receive information from accessterminal (AT) 122 over reverse link 124. In a FDD system, communicationlinks 118, 120, 124 and 126 may use different frequency forcommunication. For example, forward link 120 may use a differentfrequency then that used by reverse link 118.

Each group of antennas and/or the area in which they are designed tocommunicate is often referred to as a sector of the access network. Inthe embodiment, antenna groups each are designed to communicate toaccess terminals in a sector of the areas covered by access network 100.

In communication over forward links 120 and 126, the transmittingantennas of access network 100 may utilize beamforming in order toimprove the signal-to-noise ratio of forward links for the differentaccess terminals 116 and 122. Also, an access network using beamformingto transmit to access terminals scattered randomly through its coveragecauses less interference to access terminals in neighboring cells thanan access network transmitting through a single antenna to all itsaccess terminals.

An access network (AN) may be a fixed station or base station used forcommunicating with the terminals and may also be referred to as anaccess point, a Node B, a base station, an enhanced base station, anevolved Node B (eNB), a network node, a network, or some otherterminology. An access terminal (AT) may also be called user equipment(UE), a wireless communication device, terminal, access terminal or someother terminology.

FIG. 2 is a simplified block diagram of an embodiment of a transmittersystem 210 (also known as the access network) and a receiver system 250(also known as access terminal (AT) or user equipment (UE)) in a MIMOsystem 200. At the transmitter system 210, traffic data for a number ofdata streams is provided from a data source 212 to a transmit (TX) dataprocessor 214.

In one embodiment, each data stream is transmitted over a respectivetransmit antenna. TX data processor 214 formats, codes, and interleavesthe traffic data for each data stream based on a particular codingscheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot datausing OFDM techniques. The pilot data is typically a known data patternthat is processed in a known manner and may be used at the receiversystem to estimate the channel response. The multiplexed pilot and codeddata for each data stream is then modulated (i.e., symbol mapped) basedon a particular modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM)selected for that data stream to provide modulation symbols. The datarate, coding, and modulation for each data stream may be determined byinstructions performed by processor 230.

The modulation symbols for all data streams are then provided to a TXMIMO processor 220, which may further process the modulation symbols(e.g., for OFDM). TX MIMO processor 220 then provides N_(T) modulationsymbol streams to N_(T) transmitters (TMTR) 222 a through 222 t. Incertain embodiments, TX MIMO processor 220 applies beamforming weightsto the symbols of the data streams and to the antenna from which thesymbol is being transmitted.

Each transmitter 222 receives and processes a respective symbol streamto provide one or more analog signals, and further conditions (e.g.,amplifies, filters, and upconverts) the analog signals to provide amodulated signal suitable for transmission over the MIMO channel. N_(T)modulated signals from transmitters 222 a through 222 t are thentransmitted from N_(T) antennas 224 a through 224 t, respectively.

At receiver system 250, the transmitted modulated signals are receivedby N_(R) antennas 252 a through 252 r and the received signal from eachantenna 252 is provided to a respective receiver (RCVR) 254 a through254 r. Each receiver 254 conditions (e.g., filters, amplifies, anddownconverts) a respective received signal, digitizes the conditionedsignal to provide samples, and further processes the samples to providea corresponding “received” symbol stream.

An RX data processor 260 then receives and processes the N_(R) receivedsymbol streams from N_(R) receivers 254 based on a particular receiverprocessing technique to provide N_(T) “detected” symbol streams. The RXdata processor 260 then demodulates, deinterleaves, and decodes eachdetected symbol stream to recover the traffic data for the data stream.The processing by RX data processor 260 is complementary to thatperformed by TX MIMO processor 220 and TX data processor 214 attransmitter system 210.

A processor 270 periodically determines which pre-coding matrix to use(discussed below). Processor 270 formulates a reverse link messagecomprising a matrix index portion and a rank value portion.

The reverse link message may comprise various types of informationregarding the communication link and/or the received data stream. Thereverse link message is then processed by a TX data processor 238, whichalso receives traffic data for a number of data streams from a datasource 236, modulated by a modulator 280, conditioned by transmitters254 a through 254 r, and transmitted back to transmitter system 210.

At transmitter system 210, the modulated signals from receiver system250 are received by antennas 224, conditioned by receivers 222,demodulated by a demodulator 240, and processed by a RX data processor242 to extract the reserve link message transmitted by the receiversystem 250. Processor 230 then determines which pre-coding matrix to usefor determining the beamforming weights then processes the extractedmessage.

Turning to FIG. 3, this figure shows an alternative simplifiedfunctional block diagram of a communication device according to oneembodiment of the invention. As shown in FIG. 3, the communicationdevice 300 in a wireless communication system can be utilized forrealizing the UEs (or ATs) 116 and 122 in FIG. 1 or the base station (orAN) 100 in FIG. 1, and the wireless communications system is preferablythe NR system. The communication device 300 may include an input device302, an output device 304, a control circuit 306, a central processingunit (CPU) 308, a memory 310, a program code 312, and a transceiver 314.The control circuit 306 executes the program code 312 in the memory 310through the CPU 308, thereby controlling an operation of thecommunications device 300. The communications device 300 can receivesignals input by a user through the input device 302, such as a keyboardor keypad, and can output images and sounds through the output device304, such as a monitor or speakers. The transceiver 314 is used toreceive and transmit wireless signals, delivering received signals tothe control circuit 306, and outputting signals generated by the controlcircuit 306 wirelessly. The communication device 300 in a wirelesscommunication system can also be utilized for realizing the AN 100 inFIG. 1.

FIG. 4 is a simplified block diagram of the program code 312 shown inFIG. 3 in accordance with one embodiment of the invention. In thisembodiment, the program code 312 includes an application layer 400, aLayer 3 portion 402, and a Layer 2 portion 404, and is coupled to aLayer 1 portion 406. The Layer 3 portion 402 generally performs radioresource control. The Layer 2 portion 404 generally performs linkcontrol. The Layer 1 portion 406 generally performs physicalconnections.

3GPP TS 23.287 specifies procedures related to unicast mode V2Xcommunication over PC5 reference point as follows:

5.1.2 Authorization and Provisioning for V2X Communications Over PC5Reference Point 5.1.2.1 Policy/Parameter Provisioning

The following sets of information for V2X communications over PC5reference point is provisioned to the UE:

-   -   1) Authorization policy:        -   When the UE is “served by E-UTRA” or “served by NR”:            -   PLMNs in which the UE is authorized to perform V2X                communications over PC5 reference point when “served by                E-UTRA” or “served by NR”.            -   For each above PLMN:                -   RAT(s) over which the UE is authorized to perform                    V2X communications over PC5 reference point.        -   When the UE is “not served by E-UTRA” and “not served by            NR”:            -   Indicates whether the UE is authorized to perform V2X                communications over PC5 reference point when “not served                by E-UTRA” and “not served by NR”.            -   RAT(s) over which the UE is authorized to perform V2X                communications over PC5 reference point.    -   NOTE 1: In this specification, {When the UE is “served by        E-UTRA” or “served by NR”} and {When the UE is “not served by        E-UTRA” and “not served by NR”} are relevant to V2X        communications over PC5 reference point.    -   2) Radio parameters when the UE is “not served by E-UTRA” and        “not served by NR”:        -   Includes the radio parameters per PC5 RAT (i.e. LTE PC5, NR            PC5) with Geographical Area(s) and an indication of whether            they are “operator managed” or “non-operator managed”. These            radio parameters (e.g., frequency bands) are defined in TS            36.331 [14] and TS 38.331 [15]. The UE uses the radio            parameters to perform V2X communications over PC5 reference            point when “not served by E-UTRA” and “not served by NR”            only if the UE can reliably locate itself in the            corresponding Geographical Area. Otherwise, the UE is not            authorized to transmit.    -   NOTE 2: Whether a frequency band is “operator managed” or        “non-operator managed” in a given Geographical Area is defined        by local regulations.    -   3) Policy/parameters per RAT for PC5 Tx Profile selection:        -   The mapping of V2X service types (e.g. PSIDs or ITS-AIDS) to            Tx Profiles (see TS 36.300 [9] and TS 38.300 [11] for            further information).    -   4) Policy/parameters related to privacy:        -   The list of V2X service types, e.g. PSIDs or ITS-AIDS of the            V2X applications, with Geographical Area(s) that require            privacy support.        -   A privacy timer value indicating the duration after which            the UE shall change each source Layer-2 ID self-assigned by            the UE when privacy is required.    -   5) Policy/parameters when LTE PC5 is selected:        -   Same as specified in TS 23.285 [8] clause 4.4.1.1.2 item 3)            Policy/parameters except for the mapping of V2X service            types to Tx Profiles and the list of V2X services with            Geographical Area(s) that require privacy support.    -   6) Policy/parameters when NR PC5 is selected:        -   The mapping of V2X service types (e.g. PSIDs or ITS-AIDS) to            V2X frequencies with Geographical Area(s).        -   The mapping of Destination Layer-2 ID(s) and the V2X service            types, e.g. PSIDs or ITS-AIDs of the V2X application for            broadcast.        -   The mapping of Destination Layer-2 ID(s) and the V2X service            types, e.g. PSIDs or ITS-AIDs of the V2X application for            groupcast.        -   The mapping of default Destination Layer-2 ID(s) for initial            signalling to establish unicast connection and the V2X            service types, e.g. PSIDs or ITS-AIDS of the V2X            application.    -   NOTE 3: The same default Destination Layer-2 ID for unicast        initial signalling can be mapped to more than one V2X service        types. In the case where different V2X services are mapped to        distinct default Destination Layer-2 IDs, when the UE intends to        establish a single unicast link that can be used for more than        one V2X service types, the UE can select any of the default        Destination Layer-2 IDs to use for the initial signalling.        -   PC5 QoS mapping configuration:            -   Input from V2X application layer:                -   V2X service type (e.g. PSID or ITS-AID).                -   (Optional) V2X Application Requirements for the V2X                    service type, e.g. priority requirement, reliability                    requirement, delay requirement, range requirement.    -   NOTE 4: Details of V2X Application Requirements for the V2X        service type is up to implementation and out of scope of this        specification.        -   Output:            -   PC5 QoS parameters defined in clause 5.4.2 (i.e. PQI and                conditionally other parameters such as MFBR/GFBR, etc.).    -   AS layer configurations (see TS 38.331 [15]), e.g. the mapping        of PC5 QoS profile(s) to radio bearer(s), when the UE is “not        served by E-UTRA” and “not served by NR”.        -   The PC5 QoS profile contains PC5 QoS parameters described in            clause 5.4.2, and value for the QoS characteristics            regarding Priority Level, Averaging Window, Maximum Data            Burst Volume if default value is not used as defined in            Table 5.4.4-1.    -   7) Validity timer indicating the expiration time of the V2X        Policy/Parameter.

The above parameter sets from bullet 2) to 6) may be configured in theUE through the V1 reference point by the V2X Application Server.

[ . . . ]

5.2.1.4 Unicast Mode Communication Over PC5 Reference Point

Unicast mode of communication is only supported over NR based PC5reference point. FIG. 5.2.1.4-1 illustrates an example of PC5 unicastlinks.

FIG. 5.2.1.4-1 of 3GPP TS 23.287 V16.2.0, Entitled “Example of PC5Unicast Links”, is Reproduced as FIG. 5

The following principles apply when the V2X communication is carriedover PC5 unicast link:

-   -   A PC5 unicast link between two UEs allows V2X communication        between one or more pairs of peer V2X services in these UEs. All        V2X services in the UE using the same PC5 unicast link use the        same Application Layer ID.    -   NOTE 1: An Application Layer ID can change in time as described        in clauses 5.6.1.1 and 6.3.3.2, due to privacy. This does not        cause a re-establishment of a PC5 unicast link. The UE triggers        a Link Identifier Update procedure as specified in clause        6.3.3.2.    -   One PC5 unicast link supports one or more V2X service types        (e.g. PSIDs or ITS-AIDS) if these V2X service types are at least        associated with the pair of peer Application Layer IDs for this        PC5 unicast link. For example, as illustrated in FIG. 5.2.1.4-1,        UE A and UE B have two PC5 unicast links, one between peer        Application Layer ID 1/UE A and Application Layer ID 2/UE B and        one between peer Application Layer ID 3/UE A and Application        Layer ID 4/UE B.    -   NOTE 2: A source UE is not required to know whether different        target Application Layer IDs over different PC5 unicast links        belong to the same target UE.    -   A PC5 unicast link supports V2X communication using a single        network layer protocol e.g. IP or non-IP.    -   A PC5 unicast link supports per-flow QoS model as specified in        clause 5.4.1.

When the Application layer in the UE initiates data transfer for a V2Xservice type which requires unicast mode of communication over PC5reference point:

-   -   the UE shall reuse an existing PC5 unicast link if the pair of        peer Application Layer IDs and the network layer protocol of        this PC5 unicast link are identical to those required by the        application layer in the UE for this V2X service, and modify the        existing PC5 unicast link to add this V2X service type as        specified in clause 6.3.3.4; otherwise    -   the UE shall trigger the establishment of a new PC5 unicast link        as specified in clause 6.3.3.1.

After successful PC5 unicast link establishment, UE A and UE B use thesame pair of Layer-2 IDs for subsequent PC5-S signalling messageexchange and V2X service data transmission as specified in clause5.6.1.4. The V2X layer of the transmitting UE indicates to the AS layerwhether a transmission is for a PC5-S signalling message (i.e. DirectCommunication Request/Accept, Link Identifier UpdateRequest/Response/Ack, Disconnect Request/Response, Link ModificationRequest/Accept) or V2X service data.

For every PC5 unicast link, a UE self-assigns a distinct PC5 LinkIdentifier that uniquely identifies the PC5 unicast link in the UE forthe lifetime of the PC5 unicast link. Each PC5 unicast link isassociated with a Unicast Link Profile which includes:

-   -   V2X service type(s) (e.g. PSID(s) or ITS-AID(s)); and    -   Application Layer ID and Layer-2 ID of UE A; and    -   Application Layer ID and Layer-2 ID of UE B; and    -   network layer protocol used on the PC5 unicast link; and    -   for each V2X service type, a set of PC5 QoS Flow Identifier(s)        (PFI(s)). Each PFI is associated with QoS parameters (i.e. PQI).

For privacy reason, the Application Layer IDs and Layer-2 IDs may changeas described in clauses 5.6.1.1 and 6.3.3.2 during the lifetime of thePC5 unicast link and, if so, shall be updated in the Unicast LinkProfile accordingly. The UE uses PC5 Link Identifier to indicate the PC5unicast link to V2X Application layer, therefore V2X Application layeridentifies the corresponding PC5 unicast link even if there are morethan one unicast link associated with one V2X service type (e.g. the UEestablishes multiple unicast links with multiple UEs for a same V2Xservice type).

The Unicast Link Profile shall be updated accordingly after a Layer-2link modification for an established PC5 unicast link as specified inclause 6.3.3.4 or Layer-2 link identifier update as specified in clause6.3.3.2.

V2X Service Info and QoS Info are carried in PC5-S signalling messagesand exchanged between two UEs as specified in clause 6.3.3. Based on theexchanged information, PFI is used to identify V2X service. When thereceiving UE receives V2X service data over the established PC5 unicastlink, the receiving UE determines the appropriate V2X service based onthe PFI to forward the received V2X service data to the upper layer.

Upon receiving an indication from the AS layer that the PC5-RRCconnection was released due to RLF, the V2X layer in the UE locallyreleases the PC5 unicast link associated with this PC5-RRC connection.The AS layer uses PC5 Link Identifier to indicate the PC5 unicast linkwhose PC5-RRC connection was released.

When the PC5 unicast link has been released as specified in clause6.3.3.3, the V2X layer of each UE for the PC5 unicast link informs theAS layer that the PC5 unicast link has been released. The V2X layer usesPC5 Link Identifier to indicate the released unicast link.

[ . . . ]

5.6.1.4 Identifiers for Unicast Mode V2X Communication Over PC5Reference Point

For unicast mode of V2X communication over PC5 reference point, thedestination Layer-2 ID used depends on the communication peer. TheLayer-2 ID of the communication peer, identified by the ApplicationLayer ID, may be discovered during the establishment of the PC5 unicastlink, or known to the UE via prior V2X communications, e.g. existing orprior unicast link to the same Application Layer ID, or obtained fromapplication layer service announcements. The initial signalling for theestablishment of the PC5 unicast link may use the known Layer-2 ID ofthe communication peer, or a default destination Layer-2 ID associatedwith the V2X service type (e.g. PSID/ITS-AID) configured for PC5 unicastlink establishment, as specified in clause 5.1.2.1. During the PC5unicast link establishment procedure, Layer-2 IDs are exchanged, andshould be used for future communication between the two UEs, asspecified in clause 6.3.3.1.

The Application Layer ID is associated with one or more V2X applicationswithin the UE. If UE has more than one Application Layer IDs, eachApplication Layer ID of the same UE may be seen as different UE'sApplication Layer ID from the peer UE's perspective.

The UE maintains a mapping between the Application Layer IDs and thesource Layer-2 IDs used for the PC5 unicast links, as the V2Xapplication layer does not use the Layer-2 IDs. This allows the changeof source Layer-2 ID without interrupting the V2X applications.

When Application Layer IDs change, the source Layer-2 ID(s) of the PC5unicast link(s) shall be changed if the link(s) was used for V2Xcommunication with the changed Application Layer IDs.

Based on privacy configuration as specified in clause 5.1.2.1, theupdate of the new identifiers of a source UE to the peer UE for theestablished unicast link may cause the peer UE to change its Layer-2 IDand optionally IP address/prefix if IP communication is used as definedin clause 6.3.3.2.

A UE may establish multiple PC5 unicast links with a peer UE and use thesame or different source Layer-2 IDs for these PC5 unicast links.

[ . . . ]

6.1 Control and User Plane Stacks 6.1.1 User Plane for NR PC5 ReferencePoint Supporting V2X Services

FIG. 6.1.1-1 depicts a user plane for NR PC5 reference point, i.e. PC5User Plane Protocol stack.

FIG. 6.1.1-1 of 3GPP TS 23.287 V16.2.0, Entitled “User Plane for NR PC5Reference Point”, is Reproduced as FIG. 6

IP and Non-IP PDCP SDU types are supported for the V2X communicationover PC5 reference point.

For IP PDCP SDU type, only IPv6 is supported. The IP address allocationand configuration are as defined in clause 5.6.1.1.

The Non-IP PDCP SDU contains a Non-IP Type header, which indicates theV2X message family used by the application layer, e.g. IEEE 1609family's WSMP [18], ISO defined FNTP [19].

-   -   NOTE: The Non-IP Type header and allowed values are defined in        TS 24.587 [24].

The packets from V2X application layer are handled by the V2X layerbefore transmitting them to the AS layer, e.g. V2X layer maps the IP/NonIP packets to PC5 QoS Flow and marks the corresponding PFI.

6.1.2 Control Plane for NR PC5 Reference Point Supporting V2X Services

-   Editor's note: Whether PC5-S messages are carried in PC5 RRC    signalling depends on RAN decision.    FIG. 6.1.2-1 depicts a control plane for NR PC5 reference point,    i.e. PC5 Signalling Protocol stack.

FIG. 6.1.2-1 of 3GPP TS 23.287 V16.2.0, Entitled “Control Plane for NRPC5 Reference Point”, is Reproduced as FIG. 7

[ . . . ]

6.3.3 Unicast Mode V2X Communication Over PC5 Reference Point 6.3.3.1Layer-2 Link Establishment Over PC5 Reference Point

To perform unicast mode of V2X communication over PC5 reference point,the UE is configured with the related information as described in clause5.1.2.1.

FIG. 6.3.3.1-1 shows the layer-2 link establishment procedure forunicast mode of V2X communication over PC5 reference point.

FIG. 6.3.3.1-1 of 3GPP TS 23.287 V16.2.0, Entitled “Layer-2 LinkEstablishment Procedure”, is Reproduced as FIG. 8

-   -   1. The UE(s) determine the destination Layer-2 ID for signalling        reception for PC5 unicast link establishment as specified in        clause 5.6.1.4. The destination Layer-2 ID is configured with        the UE(s) as specified in clause 5.1.2.1.    -   2. The V2X application layer in UE-1 provides application        information for PC5 unicast communication. The application        information includes the V2X service type(s) (e.g. PSID(s) or        ITS-AID(s)) of the V2X application and the initiating UE's        Application Layer ID. The target UE's Application Layer ID may        be included in the application information.        -   The V2X application layer in UE-1 may provide V2X            Application Requirements for this unicast communication.            UE-1 determines the PC5 QoS parameters and PFI as specified            in clause 5.4.1.4.        -   If UE-1 decides to reuse the existing PC5 unicast link as            specified in clause 5.2.1.4, the UE triggers Layer-2 link            modification procedure as specified in clause 6.3.3.4.    -   3. UE-1 sends a Direct Communication Request message to initiate        the unicast layer-2 link establishment procedure. The Direct        Communication Request message includes:        -   Source User Info: the initiating UE's Application Layer ID            (i.e. UE-Vs Application Layer ID).        -   If the V2X application layer provided the target UE's            Application Layer ID in step 2, the following information is            included:            -   Target User Info: the target UE's Application Layer ID                (i.e. UE-2's Application Layer ID).        -   V2X Service Info: the information about V2X Service(s)            requesting Layer-2 link establishment (e.g. PSID(s) or            ITS-AID(s)).        -   Security Information: the information for the establishment            of security.    -   NOTE 1: The Security Information and the necessary protection of        the Source User Info and Target User Info are defined by SA WG3.        -   The source Layer-2 ID and destination Layer-2 ID used to            send the Direct Communication Request message are determined            as specified in clauses 5.6.1.1 and 5.6.1.4. The destination            Layer-2 ID may be broadcast or unicast Layer-2 ID. When            unicast Layer-2 ID is used, the Target User Info shall be            included in the Direct Communication Request message.        -   UE-1 sends the Direct Communication Request message via PC5            broadcast or unicast using the source Layer-2 ID and the            destination Layer-2 ID.    -   4. Security with UE-1 is established as below:    -   4a. If the Target User Info is included in the Direct        Communication Request message, the target UE, i.e. UE-2,        responds by establishing the security with UE-1.    -   4b. If the Target User Info is not included in the Direct        Communication Request message, the UEs that are interested in        using the announced V2X Service(s) over a PC5 unicast link with        UE-1 responds by establishing the security with UE-1.    -   NOTE 2: The signalling for the Security Procedure is defined by        SA WG3.        -   When the security protection is enabled, UE-1 sends the            following information to the target UE:            -   If IP communication is used:                -   IP Address Configuration: For IP communication, IP                    address configuration is required for this link and                    indicates one of the following values:                -    “IPv6 Router” if IPv6 address allocation mechanism                    is supported by the initiating UE, i.e., acting as                    an IPv6 Router; or                -    “IPv6 address allocation not supported” if IPv6                    address allocation mechanism is not supported by the                    initiating UE.                -   Link Local IPv6 Address: a link-local IPv6 address                    formed locally based on RFC 4862 [21] if UE-1 does                    not support the IPv6 IP address allocation                    mechanism, i.e. the IP Address Configuration                    indicates “IPv6 address allocation not supported”.            -   QoS Info: the information about PC5 QoS Flow(s). For                each PC5 QoS Flow, the PFI and the corresponding PC5 QoS                parameters (i.e. PQI and conditionally other parameters                such as MFBR/GFBR, etc.).        -   The source Layer-2 ID used for the security establishment            procedure is determined as specified in clauses 5.6.1.1 and            5.6.1.4. The destination Layer-2 ID is set to the source            Layer-2 ID of the received Direct Communication Request            message.        -   Upon receiving the security establishment procedure            messages, UE-1 obtains the peer UE's Layer-2 ID for future            communication, for signalling and data traffic for this            unicast link.    -   5. A Direct Communication Accept message is sent to UE-1 by the        target UE(s) that has successfully established security with        UE-1:        -   5a. (UE oriented Layer-2 link establishment) If the Target            User Info is included in the Direct Communication Request            message, the target UE, i.e. UE-2 responds with a Direct            Communication Accept message if the Application Layer ID for            UE-2 matches.        -   5b. (V2X Service oriented Layer-2 link establishment) If the            Target User Info is not included in the Direct Communication            Request message, the UEs that are interested in using the            announced V2X Service(s) respond to the request by sending a            Direct Communication Accept message (UE-2 and UE-4 in FIG.            6.3.3.1-1).        -   The Direct Communication Accept message includes:            -   Source User Info: Application Layer ID of the UE sending                the Direct Communication Accept message.            -   QoS Info: the information about PC5 QoS Flow(s). For                each PC5 QoS Flow, the PFI and the corresponding PC5 QoS                parameters requested by UE-1 (i.e. PQI and conditionally                other parameters such as MFBR/GFBR, etc).            -   If IP communication is used:                -   IP Address Configuration: For IP communication, IP                    address configuration is required for this link and                    indicates one of the following values:                -    “IPv6 Router” if IPv6 address allocation mechanism                    is supported by the target UE, i.e., acting as an                    IPv6 Router; or                -    “IPv6 address allocation not supported” if IPv6                    address allocation mechanism is not supported by the                    target UE.                -   Link Local IPv6 Address: a link-local IPv6 address                    formed locally based on RFC 4862 [21] if the target                    UE does not support the IPv6 IP address allocation                    mechanism, i.e. the IP Address Configuration                    indicates “IPv6 address allocation not supported”,                    and UE-1 included a link-local IPv6 address in the                    Direct Communication Request message. The target UE                    shall include a non-conflicting link-local IPv6                    address.        -   If both UEs (i.e. the initiating UE and the target UE)            selected to use link-local IPv6 address, they shall disable            the duplicate address detection defined in RFC 4862 [21].    -   NOTE 3: When either the initiating UE or the target UE indicates        the support of IPv6 router, corresponding address configuration        procedure would be carried out after the establishment of the        layer 2 link, and the link-local IPv6 addresses are ignored.        -   The V2X layer of the UE that established PC5 unicast link            passes the PC5 Link Identifier assigned for the unicast link            and the PC5 unicast link related information down to the AS            layer. The PC5 unicast link related information includes            Layer-2 ID information (i.e. source Layer-2 ID and            destination Layer-2 ID). This enables the AS layer to            maintain the PC5 Link Identifier together with the PC5            unicast link related information.    -   6. V2X service data is transmitted over the established unicast        link as below:        -   The PC5 Link Identifier, and PFI are provided to the AS            layer, together with the V2X service data.        -   Optionally in addition, the Layer-2 ID information (i.e.            source Layer-2 ID and destination Layer-2 ID) is provided to            the AS layer.    -   NOTE 4: It is up to UE implementation to provide the Layer-2 ID        information to the AS layer.        -   UE-1 sends the V2X service data using the source Layer-2 ID            (i.e. UE-1's Layer-2 ID for this unicast link) and the            destination Layer-2 ID (i.e. the peer UE's Layer-2 ID for            this unicast link).    -   NOTE 5: PC5 unicast link is bi-directional, therefore the peer        UE of UE-1 can send the V2X service data to UE-1 over the        unicast link with UE-1.

3GPP TS 24.587 specifies Stage 3 PC5 unicast link establishmentprocedure as follows:

6.1.2.2 PC5 Unicast Link Establishment Procedure 6.1.2.2.1 General

The PC5 unicast link establishment procedure is used to establish a PC5unicast link between two UEs. The UE sending the request message iscalled the “initiating UE” and the other UE is called the “target UE”.

Editor's note: The details about security procedure defined by SA3 areFFS.

Editor's note: The details of the IEs of the following messages are FFS.

6.1.2.2.2 PC5 Unicast Link Establishment Procedure Initiation byInitiating UE

-   -   Editor's note: This section needs to be revisited after SA3 have        determined the full set of security requirements for unicast        link establishment.

The initiating UE shall meet the following pre-conditions beforeinitiating this procedure:

-   -   a) a request from upper layers to transmit the packet for V2X        service over PC5;    -   b) the link layer identifier for the initiating UE (i.e. layer 2        ID used for unicast communication) is available (e.g.        pre-configured or self-assigned);    -   c) the link layer identifier for the unicast initial signaling        (i.e. destination layer 2 ID used for unicast initial signaling)        is available to the initiating UE (e.g. pre-configured, obtained        as specified in clause 5.2.3 or known via prior V2X        communication);    -   d) the initiating UE is either authorised for V2X communication        over PC5 in NR in the serving PLMN, or has a valid authorization        for V2X communication over PC5 in NR when not served by E-UTRAN        and not served by NR; and    -   e) there is no existing PC5 unicast link for the pair of peer        application layer IDs and the network layer protocol of this PC5        unicast link are identical to those required by the upper layer        in the initiating UE for this V2X service.

In order to initiate the PC5 unicast link establishment procedure, theinitiating UE shall create a DIRECT LINK ESTABLISHMENT REQUEST message.The initiating UE:

-   -   a) shall include the source user info set to the initiating UE's        application layer ID received from upper layers;    -   b) shall include the V2X service identifier received from upper        layer;    -   c) may include the target user info set to the target UE's        application layer ID if received from upper layers; and    -   d) shall include the security establishment information.    -   Editor's note: The parameters in the security establishment        information will be defined by SA3.

After the DIRECT LINK ESTABLISHMENT REQUEST message is generated, theinitiating UE shall pass this message to the lower layers fortransmission along with the initiating UE's Layer 2 ID for unicastcommunication and the destination layer 2 ID used for unicast initialsignaling, and start timer T5000. The UE shall not send a new DIRECTLINK ESTABLISHMENT REQUEST message to the same target UE identified bythe same application layer ID while timer T5000 is running.

FIG. 6.1.2.2.2 of 3GPP TS 24.587 V16.0.0, Entitled “PC5 Unicast LinkEstablishment Procedure”, is Reproduced as FIG. 9 6.1.2.2.3 PC5 UnicastLink Establishment Procedure Accepted by the Target UE

Upon receipt of a DIRECT LINK ESTABLISHMENT REQUEST message, the targetUE shall assign a layer-2 ID for this PC5 unicast link and store thisassigned layer-2 ID and the source layer 2 ID used in the transport ofthis message provided by the lower layers. This pair of layer-2 IDs isassociated with a PC5 unicast link context.

If:

-   -   a) the target user info IE is included in the DIRECT LINK        ESTABLISHMENT REQUEST message and this IE includes the target        UE's application layer ID; or    -   b) the target user info IE is not included in the DIRECT LINK        ESTABLISHMENT REQUEST message and the target UE is interested in        the V2X service identified by the V2X service identifier in the        DIRECT LINK ESTABLISHMENT REQUEST message;        then the target UE shall either identify an existing security        context with the initiating UE, or establish a new security        context by performing one or more PC5 unicast link        authentication procedures as specified in clause 6.1.2.6, and        performing the PC5 unicast link security mode control procedure        as specified in clause 6.1.2.7.

Upon successful completion of the PC5 unicast link security mode controlprocedure, in order to determine whether the DIRECT LINK ESTABLISHMENTREQUEST message can be accepted or not, in case of IP communication, thetarget UE checks whether there is at least one common IP addressconfiguration option supported by both the initiating UE and the targetUE.

If the target UE accepts the PC5 unicast link establishment procedure,the target UE shall create a DIRECT LINK ESTABLISHMENT ACCEPT message.The target UE:

-   -   a) shall include the source user info set to the target UE's        application layer ID received from upper layers;    -   b) shall include a PQFI and the corresponding PC5 QoS        parameters;    -   c) may include an IP address configuration IE set to one of the        following values if IP communication is used:        -   1) “IPv6 router” if only IPv6 address allocation mechanism            is supported by the target UE, i.e. acting as an IPv6            router; or        -   2) “IPv6 address allocation not supported” if IPv6 address            allocation mechanism is not supported by the target UE;    -   d) may include a link local IPv6 address IE formed locally based        on IETF RFC 4862 [16] if IP address configuration IE is set to        “IPv6 address allocation not supported” and the received DIRECT        LINK ESTABLISHMENT REQUEST message included a link local IPv6        address IE.

6.1.2.2.4 PC5 Unicast Link Establishment Procedure Completion by theInitiating UE

Upon receipt of the DIRECT LINK ESTABLISHMENT ACCEPT message, theinitiating UE shall stop timer T5000 and store the source layer-2 ID andthe destination Layer-2 ID used in the transport of this messageprovided by the lower layers. This pair of layer-2 IDs shall beassociated with a PC5 unicast link context. From this time onward theinitiating UE shall use the established link for V2X communication overPC5 and additional PC5 signalling messages to the target UE.

6.1.2.2.5 PC5 Unicast Link Establishment Procedure not Accepted by theTarget UE

lithe DIRECT LINK ESTABLISHMENT REQUEST message cannot be accepted, thetarget UE shall send a DIRECT LINK ESTABLISHMENT REJECT message. TheDIRECT LINK ESTABLISHMENT REJECT message contains a PC5 signallingprotocol cause IE set to one of the following cause values:

-   -   #1 direct communication to the target UE not allowed;    -   #3 conflict of Layer 2 ID for unicast communication is detected;    -   #5 lack of resources for proposed link; or    -   #111 protocol error, unspecified.

If the target UE is not allowed to accept this request .e.g. based onoperator policy or service authorisation provisioning, the target UEshall send a DIRECT LINK ESTABLISHMENT REJECT message containing PC5signalling protocol cause value #1 “direct communication to the targetUE not allowed”.

For a received DIRECT LINK ESTABLISHMENT REQUEST message from a Layer 2ID (for unicast communication), if the target UE already has an existinglink established to the UE known to use this Layer 2 ID or is currentlyprocessing a DIRECT LINK ESTABLISHMENT REQUEST message from the sameLayer 2 ID, but with user info different from the user info IE includedin this new incoming message, the target UE shall send a DIRECT LINKESTABLISHMENT REJECT message containing PC5 signalling protocol causevalue #3 “conflict of Layer 2 ID for unicast communication is detected”.

If the PC5 unicast link establishment fails due to the congestionproblems or other temporary lower layer problems causing resourceconstraints, the target UE shall send a DIRECT LINK ESTABLISHMENT REJECTmessage containing PC5 signalling protocol cause value #5 “lack ofresources for proposed link”.

For other reasons that causing the failure of link establishment, thetarget UE shall send a DIRECT LINK ESTABLISHMENT REJECT messagecontaining PC5 signalling protocol cause value #111 “protocol error,unspecified”.

Upon receipt of the DIRECT LINK ESTABLISHMENT REJECT message, theinitiating UE shall stop timer T5000 and abort the PC5 unicast linkestablishment procedure. If the PC5 signalling protocol cause value inthe DIRECT LINK ESTABLISHMENT REJECT message is #1 “direct communicationto the target UE not allowed” or #5 “lack of resources for proposedlink”, then the UE shall not attempt to start PC5 unicast linkestablishment with the same target UE at least for a time period T.

-   -   NOTE: The length of time period T is UE implementation specific        and can be different for the case when the UE receives PC5        signalling protocol cause value #1 “direct communication to the        target UE not allowed” or when the UE receives PC5 signalling        protocol cause value #5 “lack of resources for proposed link”.

6.1.2.2.6 Abnormal Cases 6.1.2.2.6.1 Abnormal Cases at the Initiating UE

If timer T5000 expires, the initiating UE shall retransmit the DIRECTLINK ESTABLISHMENT REQUEST message and restart timer T5000. Afterreaching the maximum number of allowed retransmissions, the initiatingUE shall abort the PC5 unicast link establishment procedure and maynotify the upper layer that the target UE is unreachable.

-   -   NOTE: The maximum number of allowed retransmissions is UE        implementation specific.

If the need to establish a link no longer exists before the procedure iscompleted, the initiating UE shall abort the procedure.

6.1.2.2.6.2 Abnormal Cases at the Target UE

For a received DIRECT LINK ESTABLISHMENT REQUEST message from a sourceLayer 2 ID (for unicast communication), if the target UE already has anexisting link established to the UE known to use this source Layer 2 IDand the new request contains an identical source user info as the knownuser, the UE shall process the new request. However, the target UE shallonly delete the existing link context after the new link establishmentprocedure succeeds.

3GPP TR 23.752 introduces the issue on support of UE-to-UE Relay andrelated solutions for a new release (i.e. Release 17) as follows:

5.4 Key Issue #4: Support of UE-to-UE Relay 5.4.1 General Description

This key issue intends to support for UE-to-UE Relay, including supportfor in coverage and out of coverage operation.

At least the following aspects need to be considered in potentialsolutions:

-   -   How to (re)-select a UE-to-UE Relay UE in proximity?    -   Whether and how for the network can control the UE-to-UE Relay        operation, at least including how to:        -   Authorize the UE-to-UE Relay, e.g. authorize a UE as            UE-to-UE Relay?        -   Provide the visibility of source/target UE and the UE-to-UE            Relay to the network for the purpose of, e.g. charging?    -   How to establish the connection between the source UE and the        target UEs via UE-to-UE Relay?    -   How to provide end-to-end QoS framework to satisfy the QoS        requirements (such as data rate, reliability, latency)?    -   How to enhance the system architecture to provide the security        protection for relayed connection?    -   How to provide a mechanism for path changing in case of e.g.        UE-to-UE Relay changes?    -   NOTE 1: For the involvement of NG-RAN, coordination with RAN WGs        is needed.    -   NOTE 2: For security aspects, coordination with SA3 is needed.        [ . . . ]        6.8 Solution #8: UE-to-UE Relay Selection without Relay        Discovery

6.8.1 Description

This proposal aims to ensure the relay discovery between the source andthe target UE shall not be dependent on how the relay forward trafficbetween the source and the target UE, e.g. L2 or L3 relaying. Thissolution relies on the concept that the UE-to-UE discovery and selectioncan be integrated into the unicast link establishment procedure asdescribed in clause 6.3.3 of TS 23.287 [5].

A new field is proposed to be added in the direct communication requestto indicate whether relays can be used in the communication. The fieldcan be called relay_indication. When a UE wants to broadcast a directcommunication request, it indicates in the message whether a UE-to-UErelay could be used. For Release 17, it is assumed that the value of theindication is restricted to single hop.

When a UE-to-UE relay receives a direct communication request with therelay_indication set, then it shall decide whether to forward therequest (i.e. broadcast this request in its proximity), according toe.g. the QoS requirements in the request, the current traffic load ofthe relay, the radio conditions between the source UE and the relay UE,or some other policies (e.g. it only serves some specific UEs orservices).

It may be the situation where multiple UE-to-UE relays can be used toreach the target UE or the target UE may also directly receive thedirect communication request from the source UE. The target UE maychoose which one to reply according to e.g. signal strength, localpolicy (e.g. traffic load of the UE-to-UE relays) or operator policies(e.g. always prefer direct communication or only use some specificUE-to-UE relays).

The source UE may receive the direct communication accept message frommultiple UE-to-UE relays and also from the target UE directly, thesource UE chooses the communication path according to e.g. signalstrength, local policy (e.g. traffic load of the UE-to-UE relays) oroperator policies (e.g. always prefer direct communication or only usesome specific UE-to-UE relays).

6.8.2 Procedures FIG. 6.8.2-1 of 3GPP TR 23.752 V0.3.0, Entitled “5GProSe UE-to-UE Relay Selection”, is Reproduced as FIG. 10

FIG. 6.8.2-1 illustrates the procedure of the proposed method.

-   -   0. UEs are authorized to use the service provided by the        UE-to-UE relays. UE-to-UE relays are authorized to provide        service of relaying traffic among UEs. The authorization and the        parameter provisioning can use solutions for KI #8.    -   1. UE-1 wants to establish unicast communication with UE-2 and        the communication can be either through direct link with UE-2 or        via a UE-to-UE relay. Then UE-1 broadcasts directly        communication request with relay_indication=1. The request will        be received by relay-1, relay-2. The request may also be        received by UE-2 if it is in the proximity of UE-1.    -   2. Relay-1 and relay-2 decide to forward the request. They        broadcast the message in their proximity with        relay_indication=0. If a relay receives this message, it will        just drop it.    -   3. UE-2 receives the requests from relay-1 and relay-2.    -   4. UE-2 chooses relay-1 and replies with request accept. If UE-2        directly receives the direct communication request from UE-1, it        may choose to setup a direct communication link by sending the        request accept directly to UE-1. The response message includes        indication on the type of communication link being established        (e.g. via relay or direct).    -   5. UE-1 receives the request accept from relay-1. UE-1 chooses        path according to e.g. policies (e.g. always choose direct path        if it is possible), signal strength, etc. If UE-1 receives        request accept directly from UE-2, it may choose to setup a        direct L2 link as described in clause 6.3.3 of TS 23.287 [5],        then step 6 is skipped.    -   6. UE-1 and UE-2 setup communication link through chosen        UE-to-UE relay. The link setup information may vary depending on        the type of relay, e.g. L2 or L3 relaying.    -   NOTE 1: In order to make a relay or path selection, the source        UE can setup a timer after sending out the direct communication        request for collecting the corresponding request accept messages        before making a decision. Similarly, the target UE can also        setup a timer after receiving the first copy of the direct        communication request for collecting multiple copies of the        request from different paths before making a decision.    -   NOTE 2: In the first time when a UE receives a message from a        UE-to-UE relay, the UE needs to verify if the relay is        authorized be a UE-to-UE relay. The verification details and the        how to secure the communication between two UEs through a        UE-to-UE relay is to be defined by SA WG3.

6.8.3 Impacts on Existing Nodes and Functionality UE Impacts to SupportNew Relay Related Functions. 6.9 Solution #9: Connection EstablishmentVia UE-to-UE Layer-2 Relay 6.9.1 Description

Using the solution described in this clause, a UE-to-UE Relay enablesthe discovery of a source UE by a target UE. A UE-to-UE Relay isauthorized to relay messages between two UEs over the PC5 interface viaauthorization and provisioning, as defined in clause 6.Y Solution forKey Issue #4: UE-to-UE Relay Authorization and Provisioning.

The source UE announces its supported applications or discovers a targetUE using a known discovery mechanism, e.g. using user-oriented orservice-oriented methods as defined in TS 23.287 [5].

The UE-to-UE Relay listens for ProSe applications advertisements (e.g.Direct Discovery or Direct Communication Request messages) fromsurrounding UEs and if a broadcasted application matches one of theapplications from its provisioned relay policy/parameters, the UE-to-UERelay advertises it as a relayed application by adding a relayindication to the message.

A target UE discovers a source UE via a UE-to-UE Relay. The target UEreceives a broadcast Direct Communication Request message with a relayindication.

A secured “extended” PC5 link is set up between the source UE and thetarget UE via the UE-to-UE Relay. The source/target UEs do not knowtheir respective peer UE's L2 IDs. Source/Target UEs send messages tothe UE-to-UE Relay and receive messages through the UE-to-UE Relay.However, the security association and the PC5 unicast link areestablished directly between the source UE and target UE. The UE-to-UERelay forwards the messages in opaque mode, without the ability to read,modify their content or replay them. The source/target UEs detect thatthe communication is going through a UE-to-UE Relay upon detecting arelay indication included in the received messages.

The UE-to-UE Relay assigns itself two Relay-L2 IDs when a unicast linkis established between two peer UEs via the UE-to-UE Relay. The firstRelay-L2 ID is used when forwarding a message to the target UE. Thesecond Relay-L2 ID is used when forwarding a message to the source UE.The UE-to-UE Relay maintains a mapping table containing the mapping ofpeer UEs L2 IDs and the corresponding Relay-L2 IDs that have beenself-assigned. When receiving a message, the UE-to-UE Relay uses itsmappings table to find the source and destination IDs to be used toforward the message to the target UE. The UE-to-UE Relay uses theRelay-L2 ID specified in the destination field to find the related UEand uses the UE's L2 ID specified in the source field to find therelated Relay-L2 ID. It then updates the source and destination fieldsof the received message with its corresponding UE's L2 ID and Relay-L2ID before forwarding the message.

-   -   NOTE: Additional security-related parameters and procedures may        be needed for the protection of relay related messages. Their        definitions need to be coordinated with SA WG3.

6.9.2 Procedures

The two methods defined in TS 23.287 [5], i.e. service-oriented anduser-oriented are supported using the procedure described in thisclause.

FIG. 6.9.2-1 shows the peer discovery and unicast link establishmentover PC5 reference point via a UE-to-UE Relay.

FIG. 6.9.2-1 of 3GPP TR 23.752 V0.3.0, Entitled “ConnectionEstablishment Procedure Via a UE-to-UE Relay”, is Reproduced as FIG. 11

-   -   0. UE-to-UE Relay registers with the network and specifies its        UE-to-UE Relay capabilities. UE-to-UE Relay is provisioned from        the network with relay policy parameters and with a unique Relay        identifier (RID).    -   1. The target UEs (i.e. UE2, UE3 and UE4) determine the        destination Layer-2 ID for signalling reception for PC5 unicast        link establishment as specified in TS 23.287 [5] clause 5.6.1.4.        The destination Layer-2 ID is configured with the target UEs as        specified in TS 23.287 [5] clause 5.1.2.1.    -   2. On the source UE (i.e. UE1), the application layer provides        information to the ProSe layer for PC5 unicast communication        (e.g. broadcast Layer-2 ID, ProSe Application ID, UE's        Application Layer ID, target UE's Application Layer ID, relay        applicable indication), as specified in TS 23.287 [5] clause        6.3.3.1.    -   3. ProSe layer triggers the peer UE discovery mechanism by        sending a broadcast Direct Communication Request message. The        message is sent using the source Layer-2 ID and broadcast        Layer-2 ID as destination, and includes other parameters related        to the application offered, as specified in TS 23.287 [5] clause        6.3.3.1.    -   4. The UE-to-UE Relay receives the broadcast Direct        Communication Request message and verifies if it's configured to        relay this application, i.e. it compares the announce ProSe        Application ID with its provisioned relay policy/parameters and,        if it matches, the UE-to-UE Relay assigns itself a Relay-Layer-2        ID (e.g. R-L2 ID-a) for UE1 (i.e. related to UE1's L2 ID).

These 2 IDs (UE1's Layer-2 ID and Relay-Layer-2 ID-a) are saved in alocal mapping table. The UE-to-UE Relay overrides the source field ofthe message with its R-L2 ID-a and adds its unique relay identifier(RID) as a relay indication. This relay indication is added by theUE-to-UE Relay only on broadcast messages since these messages are sentin clear text (i.e. without any encryption or integrity protection) thusmay be modified. The UE-to-UE Relay proceeds in forwarding the broadcastDirect Communication Request message received from the source UE.

-   -   5. Target UE3 is interested in the announced application thus,        it triggers the authentication and security establishment with        UE1, via the UE-to-UE Relay. UE3 keeps track of the Relay's        identifiers, i.e. R-L2 ID-a and RID. UE3 sends the RID in a        security protected message during the authentication and        security establishment to inform UE1 that the communication is        traversing the UE-to-UE Relay identified by RID.

UE-to-UE Relay receives the message from UE3 and uses the R-L2 ID-aspecified in the destination field to find the related UE (i.e. UE1 inthis case) in its mapping table.

UE-to-UE Relay assigns itself a new Layer-2 ID (e.g. R-L2 ID-b) for UE3and stores the mapping between UE3's L2 ID and R-L2 ID-b.

UE-to-UE Relay sets the source field of the message to R-L2 ID-b andsets the destination field to UE1's Layer-2 ID (i.e. L2 ID1) retrievedfrom the mapping entry. UE-to-UE Relay sends the message to UE1.

UE1 receives the authentication message and keeps track of R-L2 ID-b andRID. R-L2 ID-b is used as the destination on subsequent messagesdestined to UE3 and sent via the UE-to-UE Relay.

Authentication and security establishment messages are exchanged betweenUE1 and UE3 via the UE-to-UE Relay. UE-to-UE Relay changes thesource/destination Layer-2 IDs based on the information saved in itslocal mapping table.

-   -   Editor's note: The Details of the authentication and security        procedure will be investigated by SA WG3 group.    -   6. Once the security is established, UE3 completes the unicast        link establishment by sending a Direct Communication Accept        message.    -   7. UE-to-UE Relay receives the message and sets the source field        of the message to the R-L2 ID-b as found in the mapping entry        and sets the destination field to the UE1's L2 ID also from the        mapping entry. UE-to-UE Relay sends the modified message to UE1.    -   8. An “extended” unicast link is established between UE1 and        UE3, via the UE-to-UE Relay. The extended link is secured end to        end, i.e. a security association has been created between UE1        and UE3. Confidentiality and/or integrity/replay protected        messages (i.e. data or PC5-S) may be exchanged between UE1 and        UE3. The UE-to-UE Relay is not involved in the security        association thus it cannot read nor modify the secured portion        of the message (which excludes the source and destination        fields).    -   Editor's note: The details of protocol stack and PC5 link        establishment is FFS and need to be co-ordinated and confirmed        by RAN WG2 group.

6.9.3 Impacts on Services, Entities and Interfaces

The solution has impacts in the following entities:

UE:

-   -   Needs to support procedures for ProSe 5G UE-to-UE Relay and        communications via a ProSe 5G UE-to-UE Relay.

3GPP TS 38.321 specifies the sidelink Medium Access Control (MAC) PacketData Unit (PDU) format as follows:

6.1.6 MAC PDU (SL-SCH)

A MAC PDU consists of one SL-SCH subheader and one or more MAC subPDUs.Each MAC subPDU consists of one of the following:

-   -   A MAC subheader only (including padding);    -   A MAC subheader and a MAC SDU;    -   A MAC subheader and a MAC CE;    -   A MAC subheader and padding.

The MAC SDUs are of variable sizes.

Each MAC subheader except SL-SCH subheader corresponds to either a MACSDU, a MAC CE, or padding.

The SL-SCH subheader is of a fixed size and consists of the seven headerfields V/R/R/R/R/SRC/DST.

FIG. 6.1.6-1 of 3GPP TS 38.321 V16.1.0, Entitled “SL-SCH MAC Subheader”,is Reproduced as FIG. 12

A MAC subheader except for padding consists of the four header fieldsR/F/LCID/L as depicted in FIG. 6.1.2-1 (with 8-bit L field) and FIG.6.1.2-2 (with 16-bit L field). A MAC subheader for MAC CE and paddingconsists of the two header fields R/LCID as depicted in FIG. 6.1.2-3.

SL MAC subPDU(s) with MAC SDU(s) is placed after the SL-SCH subheaderand before the MAC subPDU with a MAC CE and the MAC subPDU with paddingin the MAC PDU as depicted in FIG. 6.1.6-2. SL MAC subPDU with a MAC CEis placed after all the MAC subPDU(s) with MAC SDU and before the MACsubPDU with padding in the MAC PDU as depicted in FIG. 6.1.6-2. The sizeof padding can be zero.

[FIG. 6.1.6-2 of 3GPP TS 38.321 V16.1.0, Entitled “Example of a SL MACPDU”, is Reproduced as FIG. 13]

A maximum of one MAC PDU can be transmitted per TB per MAC entity.

[ . . . ]

6.2.4 MAC Subheader for SL-SCH

The MAC subheader consists of the following fields:

-   -   V: The MAC PDU format version number field indicates which        version of the SL-SCH subheader is used. The V field size is 4        bits;    -   SRC: The SRC field carries the 16 most significant bits of the        Source Layer-2 ID field set to the identifier provided by upper        layers as defined in TS 23.287 [19]. The length of the field is        16 bits;    -   DST: The DST field carries the 8 most significant bits of the        Destination Layer-2 ID set to the identifier provided by upper        layers as defined in TS 23.287 [19]. [If the V field is set to        “1”, this identifier is a unicast identifier. If the V field is        set to “2”, this identifier is a groupcast identifier. If the V        field is set to “3”, this identifier is a broadcast identifier.        The length of the field is 8 bits;    -   LCID: The Logical Channel ID field identifies the logical        channel instance or the type of the corresponding MAC CE within        the scope of one Source Layer-2 ID and Destination Layer-2 ID        pair of the corresponding MAC SDU or padding as described in        Tables 6.2.4-1 for SL-SCH. There is one LCID field per MAC        subheader except for SL-SCH subheader. The LCID field size is 6        bits;    -   L: The Length field indicates the length of the corresponding        MAC SDU in bytes. There is one L field per MAC subheader except        for subheaders corresponding to the SL-SCH subheader or padding.        The size of the L field is indicated by the F field;    -   F: The Format field indicates the size of the Length field.        There is one F field per MAC subheader except for subheaders        corresponding to the SL-SCH subheader or padding. The size of        the F field is 1 bit. The value 0 indicates 8 bits of the Length        field. The value 1 indicates 16 bits of the Length field;    -   R: Reserved bit, set to 0.

The MAC subheader is octet aligned.

Table 6.2.4-1 of 3GPP TS 38.321 V16.1.0, Entitled “Values of LCID forSL-SCH”, is Reproduced as FIG. 14

Key issue #4 in 3GPP TR 23.752-030 describes support of UE-to-UE Relayin the following release (i.e. Release 17), which means a relay may beused to support data communication between two UEs in case these two UEscannot communicate with each other directly. It is supposed that aUE-to-UE Relay needs to establish one PC5 unicast link with each of aSource UE and a Target UE such that the integrated PC5 unicast linkbetween the Source UE and the Target UE can support the concernedProximity-based Services (ProSe) service as illustrated in FIG. 15.

When a Source UE requires a UE-to-UE Relay service, the Source UE may ormay not know the Layer-2 Identity (ID) of the Target UE. If the SourceUE knows the Layer-2 ID of the Target UE, it would be beneficial for theSource UE to include the Layer-2 ID of the Target UE in a DirectCommunication Request message (or a DIRECT LINK ESTABLISHMENT REQUESTmessage) sent by the Source UE in order to connect with a UE-to-UE Relayso that the UE-to-UE Relay can transmit a new Direct CommunicationRequest message (or a new DIRECT LINK ESTABLISHMENT REQUEST message)directly addressed to the Layer-2 ID of the Target UE. By this way, atleast other UEs do not need to process the new Direct CommunicationRequest message (or the new DIRECT LINK ESTABLISHMENT REQUEST message).

In one embodiment, the Direct Communication Request message (or theDIRECT LINK ESTABLISHMENT REQUEST message) transmitted by the Source UEmay also include the Source UE's Application Layer ID, the Target UE'sApplication Layer ID, and/or Service Info of a ProSe service, inaddition to the Layer-2 ID of the Target UE. The Service Info of theProSe service may be an identity of the ProSe service e.g. a PSID or anITS-AID. And, the new Direct Communication Request message (or the newDIRECT LINK ESTABLISHMENT REQUEST message) transmitted by the UE-to-UERelay may also include the Source UE's Application Layer ID, the TargetUE's Application Layer ID, and/or the Service Info of the ProSe service.

After transmitting the new Direct Communication Request message (or thenew DIRECT LINK ESTABLISHMENT REQUEST message) to the Target UE, theUE-to-UE Relay may receive a Direct Communication Accept message (or aDIRECT LINK ESTABLISHMENT ACCEPT message) from the Target UE. In oneembodiment, the Direct Communication Accept message (or the DIRECT LINKESTABLISHMENT ACCEPT message) may include the Target UE's ApplicationLayer ID, and/or Quality of Service (QoS) Info about PC5 QoS flow(s) ofthe ProSe service.

The UE-to-UE Relay may reply another Direct Communication Accept message(or another DIRECT LINK ESTABLISHMENT ACCEPT message) to the Source UEin response to reception of the Direct Communication Request message (orthe DIRECT LINK ESTABLISHMENT REQUEST message) sent by the Source UE. Inone embodiment, the another Direct Communication Accept message (or theanother DIRECT LINK ESTABLISHMENT ACCEPT message) may include the TargetUE's Application Layer ID, and/or the QoS Info about PC5 QoS flow(s) ofthe ProSe service.

It is noted that a PC5-S message (e.g. the Direct Communication Requestmessage or the Direct Communication Accept message) is included in aMedium Access Control (MAC) Service Data Unit (SDU), while each sidelinkMAC Packet Data Unit (PDU) includes one header and at least one MAC SDU.The header includes a field SRC indicating (part of) a Source Layer-2 IDand a field DST indicating (part of) a Destination Layer-2 ID. A PC5-Smessage addressed to a Layer-2 ID means the PC5-S message is included ina sidelink MAC PDU for transmission, where the field DST in a MAC headerof the sidelink MAC PDU is set to (part of) the Layer-2 ID.

FIG. 16 illustrates an example of the above integrated PC5 unicast linkestablishment procedure.

FIG. 17 is a flow chart 1700 according to one exemplary embodiment fromthe perspective of a UE-to-UE Relay to perform a PC5 unicast linkestablishment procedure. In step 1705, the UE-to-UE Relay receives afirst PC5-S message from a first User Equipment (UE), wherein the firstPC5-S message includes a Layer-2 Identity (ID) of a second UE. In step1710, the UE-to-UE Relay transmits a second PC5-S message addressed tothe Layer-2 ID of the second UE for establishing a PC5 unicast link withthe second UE. In step 1715, the UE-to-UE Relay receives a third PC5-Smessage from the second UE, wherein the third PC5-S message istransmitted by the second UE in response to reception of the secondPC5-S message.

In one embodiment, the first PC5-S message could be transmitted by thefirst UE addressed to a default Destination Layer-2 ID associated with aUE-to-UE Relay service. The first PC5-S message may include the firstUE's Application Layer ID. The first PC5-S message may also include thesecond UE's Application Layer ID. The first PC5-S message may furtherinclude Service Info of a Proximity-based Services (ProSe) service, andthe Service Info of the ProSe service may be an identity of the ProSeservice.

In one embodiment, the second PC5-S message may include the first UE'sApplication Layer ID. The second PC5-S message may also include thesecond UE's Application Layer ID. The second PC5-S message may furtherinclude Service Info of the Proximity-based Services (ProSe) service,and the Service Info of the ProSe service may be an identity of theProSe service.

In one embodiment, the first PC5-S message or the second PC5-S messagemay be a Direct Communication Request message or a DIRECT LINKESTABLISHMENT REQUEST message, and the third PC5-S message may be aDirect Communication Accept message or a DIRECT LINK ESTABLISHMENTACCEPT message.

Referring back to FIGS. 3 and 4, in one exemplary embodiment of aUE-to-UE Relay to perform a PC5 unicast link establishment procedure.The UE-to-UE Relay 300 includes a program code 312 stored in the memory310. The CPU 308 could execute program code 312 to enable the UE-to-UERelay (i) to receive a first PC5-S message from a first User Equipment(UE), wherein the first PC5-S message includes a Layer-2 ID of a secondUE, (ii) to transmit a second PC5-S message addressed to the Layer-2 IDof the second UE for establishing a PC5 unicast link with the second UE,and (iii) to receive a third PC5-S message from the second UE, whereinthe third PC5-S message is transmitted by the second UE in response toreception of the second PC5-S message. Furthermore, the CPU 308 canexecute the program code 312 to perform all of the above-describedactions and steps or others described herein.

Various aspects of the disclosure have been described above. It shouldbe apparent that the teachings herein could be embodied in a widevariety of forms and that any specific structure, function, or bothbeing disclosed herein is merely representative. Based on the teachingsherein one skilled in the art should appreciate that an aspect disclosedherein could be implemented independently of any other aspects and thattwo or more of these aspects could be combined in various ways. Forexample, an apparatus could be implemented or a method could bepracticed using any number of the aspects set forth herein. In addition,such an apparatus could be implemented or such a method could bepracticed using other structure, functionality, or structure andfunctionality in addition to or other than one or more of the aspectsset forth herein. As an example of some of the above concepts, in someaspects concurrent channels could be established based on pulserepetition frequencies. In some aspects concurrent channels could beestablished based on pulse position or offsets. In some aspectsconcurrent channels could be established based on time hoppingsequences. In some aspects concurrent channels could be establishedbased on pulse repetition frequencies, pulse positions or offsets, andtime hopping sequences.

Those of skill in the art would understand that information and signalsmay be represented using any of a variety of different technologies andtechniques. For example, data, instructions, commands, information,signals, bits, symbols, and chips that may be referenced throughout theabove description may be represented by voltages, currents,electromagnetic waves, magnetic fields or particles, optical fields orparticles, or any combination thereof.

Those of skill would further appreciate that the various illustrativelogical blocks, modules, processors, means, circuits, and algorithmsteps described in connection with the aspects disclosed herein may beimplemented as electronic hardware (e.g., a digital implementation, ananalog implementation, or a combination of the two, which may bedesigned using source coding or some other technique), various forms ofprogram or design code incorporating instructions (which may be referredto herein, for convenience, as “software” or a “software module”), orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentdisclosure.

In addition, the various illustrative logical blocks, modules, andcircuits described in connection with the aspects disclosed herein maybe implemented within or performed by an integrated circuit (“IC”), anaccess terminal, or an access point. The IC may comprise a generalpurpose processor, a digital signal processor (DSP), an applicationspecific integrated circuit (ASIC), a field programmable gate array(FPGA) or other programmable logic device, discrete gate or transistorlogic, discrete hardware components, electrical components, opticalcomponents, mechanical components, or any combination thereof designedto perform the functions described herein, and may execute codes orinstructions that reside within the IC, outside of the IC, or both. Ageneral purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

It is understood that any specific order or hierarchy of steps in anydisclosed process is an example of a sample approach. Based upon designpreferences, it is understood that the specific order or hierarchy ofsteps in the processes may be rearranged while remaining within thescope of the present disclosure. The accompanying method claims presentelements of the various steps in a sample order, and are not meant to belimited to the specific order or hierarchy presented.

The steps of a method or algorithm described in connection with theaspects disclosed herein may be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module (e.g., including executable instructions and relateddata) and other data may reside in a data memory such as RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a harddisk, a removable disk, a CD-ROM, or any other form of computer-readablestorage medium known in the art. A sample storage medium may be coupledto a machine such as, for example, a computer/processor (which may bereferred to herein, for convenience, as a “processor”) such theprocessor can read information (e.g., code) from and write informationto the storage medium. A sample storage medium may be integral to theprocessor. The processor and the storage medium may reside in an ASIC.The ASIC may reside in user equipment. In the alternative, the processorand the storage medium may reside as discrete components in userequipment. Moreover, in some aspects any suitable computer-programproduct may comprise a computer-readable medium comprising codesrelating to one or more of the aspects of the disclosure. In someaspects a computer program product may comprise packaging materials.

While the invention has been described in connection with variousaspects, it will be understood that the invention is capable of furthermodifications. This application is intended to cover any variations,uses or adaptation of the invention following, in general, theprinciples of the invention, and including such departures from thepresent disclosure as come within the known and customary practicewithin the art to which the invention pertains.

1. A method for a User Equipment-to-User Equipment (UE-to-UE) Relay toperform a PC5 unicast link establishment procedure, comprising: theUE-to-UE Relay receives a first PC5-S message from a first UserEquipment (UE), wherein the first PC5-S message includes a Layer-2Identity (ID) of a second UE; the UE-to-UE Relay transmits a secondPC5-S message addressed to the Layer-2 ID of the second UE forestablishing a PC5 unicast link with the second UE; and the UE-to-UERelay receives a third PC5-S message from the second UE, wherein thethird PC5-S message is transmitted by the second UE in response toreception of the second PC5-S message.
 2. The method of claim 1, whereinthe first PC5-S message is transmitted by the first UE addressed to adefault Destination Layer-2 ID associated with a UE-to-UE Relay service.3. The method of claim 1, wherein the first PC5-S message includes thefirst UE's Application Layer ID.
 4. The method of claim 1, wherein thefirst PC5-S message includes the second UE's Application Layer ID. 5.The method of claim 1, wherein the first PC5-S message includes ServiceInfo of a Proximity-based Services (ProSe) service, and the Service Infoof the ProSe service is an identity of the ProSe service.
 6. The methodof claim 1, wherein the second PC5-S message includes the first UE'sApplication Layer ID.
 7. The method of claim 1, wherein the second PC5-Smessage includes the second UE's Application Layer ID.
 8. The method ofclaim 1, wherein the second PC5-S message includes Service Info of theProximity-based Services (ProSe) service, and the Service Info of theProSe service is an identity of the ProSe service.
 9. The method ofclaim 1, wherein the first PC5-S message or the second PC5-S message isa Direct Communication Request message or a DIRECT LINK ESTABLISHMENTREQUEST message, and the third PC5-S message is a Direct CommunicationAccept message or a DIRECT LINK ESTABLISHMENT ACCEPT message.
 10. A UserEquipment-to-User Equipment (UE-to-UE) Relay, comprising: a controlcircuit; a processor installed in the control circuit; and a memoryinstalled in the control circuit and operatively coupled to theprocessor; wherein the processor is configured to execute a program codestored in the memory to: receive a first PC5-S message from a first UserEquipment (UE), wherein the first PC5-S message includes a Layer-2Identity (ID) of a second UE; transmit a second PC5-S message addressedto the Layer-2 ID of the second UE for establishing a PC5 unicast linkwith the second UE; and receive a third PC5-S message from the secondUE, wherein the third PC5-S message is transmitted by the second UE inresponse to reception of the second PC5-S message.
 11. The UE-to-UERelay of claim 11, wherein the first PC5-S message is transmitted by thefirst UE addressed to a default Destination Layer-2 ID associated with aUE-to-UE Relay service.
 12. The UE-to-UE Relay of claim 11, wherein thefirst PC5-S message includes the first UE's Application Layer ID. 13.The UE-to-UE Relay of claim 11, wherein the first PC5-S message includesthe second UE's Application Layer ID.
 14. The UE-to-UE Relay of claim11, wherein the first PC5-S message includes Service Info of aProximity-based Services (ProSe) service, and the Service Info of theProSe service is an identity of the ProSe service.
 15. The UE-to-UERelay of claim 11, wherein the second PC5-S message includes the firstUE's Application Layer ID.
 16. The UE-to-UE Relay of claim 11, whereinthe second PC5-S message includes the second UE's Application Layer ID.17. The UE-to-UE Relay of claim 11, wherein the second PC5-S messageincludes Service Info of the Proximity-based Services (ProSe) service,and the Service Info of the ProSe service is an identity of the ProSeservice.
 18. The UE-to-UE Relay of claim 11, wherein the first PC5-Smessage or the second PC5-S message is a Direct Communication Requestmessage or a DIRECT LINK ESTABLISHMENT REQUEST message, and the thirdPC5-S message is a Direct Communication Accept message or a DIRECT LINKESTABLISHMENT ACCEPT message.